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Abstract 

.An  extension  of  Standard  ML  with  continuation  primitives  similar  to  those  found  in  Scheme 
is  considered.  A  number  of  alternative  type  systems  are  discussed,  and  several  programming 
examples  are  given.  The  semantics  of  type  assignment  for  a  small,  purely  functional  frag¬ 
ment  of  the  language  is  presented,  for  which  both  a  Milner-style  soundness  theorem  and  an 
observational  soundness  theorem  may  be  established. 
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1  Introduction 


First-class  continuations  axe  a  simple  and  natural  way  to  provide  access  to  the  flow  of 
evaluation  in  functional  languages.  The  ability  to  seize  the  "current  continuation"  (control 
state  of  the  evaluator)  provides  a  simple  and  natural  basis  for  defining  numerous  higher-level 
constructs  such  as  coroutines  [16],  exceptions  [42],  and  logic  variables  [8.  19].  for  supporting 
multiple  threads  of  control  [41.  IS,  29.  6],  for  providing  asynchronous  signal  handlers  [30]. 
and  for  implementing  non-blind  backtracking  [14]  and  dynamic  barriers  such  as  unwind- 
protect  [17].  Tractable  logics  for  reasoning  about  program  equivalence  in  the  presence  of 
first-clcLSs  continuations  in  an  untyped  setting  have  been  developed  [9.  10.  39].  Recent  studies 
of  continuations  have  addressed  the  question  of  their  typing  in  a  restricted  setting  [13.  12.  lo] 
and  their  impact  on  full  abstraction  results  [34]. 

The  subject  of  this  paper  is  the  extension  of  .Standard  ML  with  primitives  for  first-class 
continuations  similar  to  those  found  in  Scheme.  The  two  new  primitives  are  callcc.  for  call 
with  current  continuation,  which  takes  a  function  as  argument  and  calls  it  with  the  current 
continuation,  and  throw,  which  talces  a  continuation  and  a  value  and  passes  the  value  to 
that  continuation. 

This  paper  is  organized  as  follows.  In  Section  2  we  give  an  informal  presentation  of 
the  extension  of  ML  with  continuation  primitives,  and  illustrate  their  use  in  programming 
examples.  We  also  discuss  the  role  of  continuations  in  the  implementation  of  Standard  ML 
of  New  Jersey,  and  some  problems  that  they  raised.  In  Section  3  we  present  a  formal  system 
of  type  assignment  for  a  small  functional  fragment  of  ML.  A  denotationed  semantics  for 
this  fragment  is  given  in  Section  3.  and  the  semantics  of  type  assignment  is  considered.  The 
main  results  are  a  Milner-style  soundness  theorem  ("well-typed  programs  cannot  go  wrong" ) 
and  an  observational  soundness  theorem  (“convergent  programs  of  type  int  yield  integers"). 
Finally,  in  Section  4  we  give  an  operational  semantics  for  the  language  in  the  "natural 
semamtics’’  style  of  Plotkin  and  Kahn  [27,  3].  The  operational  presentation  illustrates  the 
extent  to  which  the  definition  of  Standcird  ML  [24]  would  have  to  be  changed  to  accommodate 
the  proposed  extension. 

We  are  grateful  to  .Andrew  .\ppel.  Stephen  Brookes.  Matthias  Felleisen.  .\ndrzej  Filinski. 
Timothy  Griffin.  John  Reppy.  Didier  Remy.  Olin  Shivers,  and  .Mads  Tofte  for  their  comments 
and  suggestions. 

2  Adding  Continuations  to  ML 

First-class  continuations  are  an  abstraction  that  evolved  from  various  nonstandard  control 
structures  such  as  Landin’s  J-operator  [21],  Reynold's  operator  escape  [32].  label  variables 
in  Gedanken  [31]  and  PAL  [7],  and  from  the  semantic  analyses  of  general  control  struc¬ 
tures,  including  jumps  [36].  Scheme  [.38]  originally  introduced  a  binding  construct  (catch 
k  body)  that  captured  its  own  expression  continuation  and  bound  it  to  the  variable  k.  with 
the  expression  body  as  the  scope  of  the  binding.  The  continuation  represents  the  “rest  of 
the  computation."  and  behaves  as  a  function  that  taJees  the  value  of  the  expression  as  its 
argument  and  yields  the  final  result  of  the  evaluation  of  the  remainder  of  the  program.  In 
a  typical  implementation  the  final  result  is  passed  to  the  interactive  top-level,  which  prints 
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the  result,  and  continues  by  evaluating  the  next  expression. 

.\round  1982  the  special-form  catch  was  replaced  by  call-with-current-continuation 
or  call/cc  for  short  [4].  The  act  of  capturing  the  current  continuation  did  not  require 
a  special  variable  binding  form,  but  could  be  performed  by  a  primitive  operator  whose 
argument  was  a  function  that  would  be  applied  to  the  captured  continuation.  Therefore, 
(catch  X  body)  becomes  (call/cc  (lambda  (x)  body))  in  Scheme.  This  is  an  example 
of  the  well-known  technique  of  replacing  a  special  variable  binding  form  with  an  operation 
acting  on  a  function,  so  that  variable  binding  is  handled  solely  by  lambda  abstraction. 

In  an  untyped  language  there  is  not  much  to  choose  between  the  functional  and  bind¬ 
ing  forms  of  continuation-capturing  construct.  However,  in  the  context  of  an  ML-like  type 
system,  the  two  differ  substantially.  To  understand  the  distinction,  it  is  helpful  to  consider 
the  interaction  between  typing  and  the  invocation  of  a  captured  continuation.  There  are 
two  main  points.  First,  continuations  arise  in  a  program  only  by  capturing  the  evaluation 
context  of  some  expression;  there  are  no  expression  forms  denoting  continuations.  Therefore 
continuations  expect  values  of  the  type  of  the  expression  whose  evaluation  context  the  con¬ 
tinuation  represents.  Second,  the  invocation  of  a  captured  continuation  discards  the  current 
evaluation  context,  passing  a  value  to  the  captured,  instead  of  the  current,  continuation. 
Although  the  passed  value  must  be  consistent  with  the  argument  type  of  the  continuation, 
the  result  type  is  unconstrained  since  invocations  of  continuations  do  not  return  to  the  eval¬ 
uation  context.  (For  similar  reasons  the  exception-raising  construct  of  Standard  ML  has 
arbitrary  result  type.) 

For  example,  if  k  is  bound  to  a  continuation  expecting  an  integer  vzdue,  we  may  invoke 
k  in  several  incompatible  type  contexts,  as  in  the  following  expression^ 

1  +  C2Lllcc(fn  k  »> 

hd(if  b 

then  [  (k  3)  •‘•id 
else  5  : :  (k  4))) 

Here  k  is  invoked  in  two  contexts,  one  t-xpecting  an  integer,  the  other  expecting  an  integer 
list.  Since  continuation  invocations  never  return,  it  makes  sense  to  regard  this  as  a  well-typed 
expression  (of  type  int  list). 

The  incorporation  of  continuation  primitives  in  ML  involves  making  two  related  decisions, 
namely  the  continuation-capturing  construct  and  the  continuation-invoking  construct.  Since 
ML  is  a  typed  language,  continuations  should  be  values  of  some  type,  say  r  cont,  the  type 
of  continuations  expecting  values  of  type  r.  The  continuation-capturing  constructs  may  then 
be  given  typing  rules  as  follows.  The  functional  form,  written  callcc  in  keeping  with  the 
.ML  lexical  conventions,  may  be  assigned  any  type  of  the  form 

(t  cont  — t)  T 

since  the  body  may  either  invoke  the  passed  continuation,  or  else  return  normally.  Written 
polymorph! cally,  the  type  of  callcc  is  then 

Vq.(q  cont  — *•  a)  -+  Q:. 

^We  (temporarily)  use  ordinary  function  application  notation  to  indicate  invocation  of  a  continuation. 
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The  vaxiable-binding  form,  written  letcc  k  in  e.  heis  the  following  typing  rule; 

.4.  k:T  cont  h  e  :  t 
.4  H  letcc  Ar  in  e  :  r 

where  A  is  a  type  assignment  giving  types  to  the  set  of  free  variables  of  e. 

The  choice  of  functional  or  binding  form  of  continuation-capturing  construct  depends  on 
the  definition  of  the  type  r  cont.  We  consider  two  possibilities:  regard  a  continuation  as 
a  function  that  is  invoked  by  application,  or  regard  a  continuation  as  a  new  form  of  value 
that  is  invoked  by  a  special  primitive.  In  the  first  case  the  type  r  cont  is  rendered  as  a 
functional  type,  whereas  in  the  second  it  is  introduced  as  a  new  primitive  type.  We  consider 
each  in  turn. 

If  continuations  are  to  be  regarded  as  functions,  some  provision  must  be  made  for  ensuring 
that  the  result  type  is  allowed  to  vary  according  to  context.  This  suggests  the  following 
polymorphic  typing; 

callcc  :  Vq.V/?.((q  —*  .3)  —*■  a)  q 

But  since  k  is  lambda-bound  in  the  expression  callcc  (fn  k  »>  .  .  . )  this  does  not  give  us 
the  freedom  to  instantiate  the  polymorphic  type  variable  3  independently  at  each  applied 
occurrence  of  k  within  the  body  of  the  abstraction.  Instead  we  are  forced  to  choose  a  single 
type  for  3  suitable  for  all  applications  of  k.  ruling  out  examples  such  as  the  one  considered 
above. 

There  are  two  ways  to  proceed.  One  involves  moving  the  quantifier  over  3  inward  ( which 
could  be  formally  justified  by  the  observation  that  0  occurs  in  a  positive  position  in  the  type 
expression),  yielding  the  typing 

callcc ;  Va.((a  — *■  38.3)  — ♦  q)  — ♦  a, 


then  replacing  the  type  33.3.  which  is  not  the  type  of  any  defined  value,  by  a  new^  primitive 
type  void,  resulting  in  the  typing 

callcc  :  Va.((Q  —>■  void)  — >•  a)  — *•  a. 

The  type  r  cont  is  then  defined  to  be  the  t}T>e  r  — »•  void.  To  match  the  type  of  a  continu¬ 
ation  invocation  (i.e.,  void)  with  its  context  we  could  either  view  void  as  a  subtype  of  all 
types  and  use  a  subsumption  rule  (which  introduces  many  of  the  complexities  of  subtyping 
into  the  type  system),  or  we  can  simply  introduce  a  polymorphic  coercion  function 


n 


ignore  :  Va.void  — *•  a 

and  surround  applications  of  continuations  with  a  ccdl  to  ignore,  as  in 


if  b  then  [  ignoreCk  3)  +  1  ] 
else  5  : :  ignore (k  4) 


(where  k  is  an  int  cont).  Statement  "A"  per  telecon  Dr.  Andre  van 

Tilborg.  Office  of  Naval  Research/code 

1133. 
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As  an  alternative  to  ignore  we  can  exploit  the  polymorphic  type  system  of  ML.  using 
letcc  instead  of  callcc.  The  idea  is  to  take  type  r  cont  to  stand  for  the  polymorphic  type 
Vq.t  — +  a.  leading  to  the  following  typing  rule  for  letcc: 

A.  k  :  Va.r  — *•  a  H  e  :  r 
.4  H  letcc  k  in  e-.T 

Since  k  is  assigned  a  pohmiorphic  type,  the  result  type,  a,  may  be  chosen  freely  on  a  case-by- 
case  basis  for  each  applied  occurrence  of  k.  This  rule  is  consistent  with  the  ML  type  system 
in  that  let-like  constructs  admit  assignment  of  polymorphic  types  to  the  bound  identifier. 
This  method  cannot  be  adapted  to  callcc.  The  required  type  has  the  form  (Vo.r  — <•  q)  — ^  r 
which  lies  outside  of  the  scope  of  the  ML  type  system.  It  is  here  that  the  two  constructs 
differ  in  an  ML-like  setting. 

■Another  way  of  typing  continuations,  and  the  one  currently  adopted  in  Standard  ML 
of  New  Jersey  [2],  is  to  abandon  the  view  that  continuations  are  functions  in  the  ordinary 
sense  and  to  consider  r  cont  as  a  primitive  type  with  an  operation  throw  for  invoking  a 
continuation.  The  type  of  throw  is  given  by 

throw  :  Va.V^.(Q!  cont)  — >  (a  — ^  3), 

and  hence  throw  is  essentially  a  coercion  that  turns  a  continuation  into  a  function,  reintro¬ 
ducing  a  separate  instance  of  the  type  parameter  3  at  each  invocation  of  the  continuation. 
Our  example  becomes 

if  b  then  C  (throw  k  3)  +  1  ] 
else  5  : :  (throw  k  4) 

where  the  first  and  second  occurrences  of  throw  receive  the  types  int  cont  — int  — +  int 
and  int  cont  — »  int  — +  int  list,  respectively. 

It  is  ezisy  to  define  the  cont  and  throw  primitives  in  terms  of  void  and  ignore: 

tjrpe  a  cont  »  a  ->  void 
fun  throw  k  x  ■  ignore (k  x) . 

Defining  void  and  ignore  in  terms  of  cont  and  throw  is  a  bit  trickier,  but  can  be  done: 

abstype  void  =  VOID 
with 

fun  ignore  (x:void)  ;  'a  » 
let  fun  loopO  •  loopO 
in  loopO 
end 

val  callcc  « 

fn  f  »>  c2Lllcc(fn  k  »> 

f( (throw  k)  :  ’a  ->  void)) 

end 
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So,  in  principle,  there  is  not  much  to  distinguish  the  two  approaches.  In  practice,  it  is  useful 
to  be  able  to  easily  distinguish  the  invocation  of  a  continuation  from  the  application  of  a 
function.  This  is  why  cont  and  throw  are  the  chosen  primitives  in  Standard  ML  of  .\ew 
Jersey. 

It  would  seem.  then,  that  there  are  essentially  two  alternatives  for  representing  continua¬ 
tions  in  ML:  as  polymorphic  functions,  using  letcc  as  the  capturing  construct,  and  values  of 
a  new  primitive  type,  using  throw  to  invoke  them.  Although  the  two  are  equivalent  for  the 
purely  functioned  fragment  of  ML.  the  approach  based  on  a  primitive  type  of  continuations 
is  better-behaved  in  the  context  of  the  full  Standard  ML  language  than  is  the  polymorphic 
approach.  The  problem  is  that  current  schemes  for  introducing  references  (assignable  cells  i 
in  -ML  preclude  the  possibility  of  storing  objects  of  polymorphic  type.  For  instance,  if  the 
identity  function  is  stored  into  a  cell,  then  a  single  instance  of  its  polymorphic  type  must  i)e 
chosen  for  aJl  subsequent  retrievals;  its  polymorphic  character  is  lost.  (See  lofte's  thesis  >40] 
for  further  discussion  of  this  point.)  Thus  if  a  continuation  was  represented  as  a  function 
of  polymorphic  result  type,  then  the  result  type,  which  is  irrelevant  since  no  result  is  ac¬ 
tually  returned,  would  have  to  be  fixed  when  the  continuation  is  stored,  rather  than  when 
it  is  invoked.  This  would  significantly  limit  the  utility  of  stored  continuations  because  all 
invocations  would  have  to  be  in  the  same  type  context.  The  approach  based  on  a  primitive 
type  of  continuations  does  not  suffer  from  this  limitation,  and  is  therefore  to  be  preferred 
for  Standard  ML. 

We  are  thus  led  to  the  following  simple  signature  for  supporting  first-class  continuations 
in  Standard  ML; 

type  o  cont 

val  callcc  :  (a  cont  —  a)  —  a 

val  throw  :  a  cont  —  a  —  f3 

(We  could  just  as  well  have  taken  letcc  as  primitive,  but  since  there  is  no  advantage  in 
doing  so,  it  is  simpler  to  introduce  callcc  as  a  new  constant  of  polymorphic  type.) 

Some  examples  will  suggest  how  first-class  continuations  are  used  in  practice.  The  sim¬ 
plest  and  earliest  use  of  continuations  was  to  provide  an  escape,  as  in  the  following  function 
that  returns  the  product  of  a  list  of  integers.  If  a  zero  is  found  the  answer  is  returned  via  a 
continuation  such  that  no  multiplications  <ire  performed. 

fun  prod  1  » 

callcc(fn  exit  ■> 
let  fun  loop  □  »  1 

I  loop(0::t)  «  throw  exit  0 
I  loop(h: :t)  »  h  *  loop  t 
in  loop  1 
end) 

.Another  common  application  is  to  implement  coroutines.  Here  cin  interesting  typing  issue 
arises.  A  common  technique  is  to  resume  a  coroutine  by  passing  the  continuation  of  the 
current  coroutine  as  the  argument  to  the  continuation  representing  the  resumed  coroutine. 
If  state  is  the  type  representing  the  state  of  a  coroutine,  this  leads  naively  to  the  circular 
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identification 

state  =  state  cost 

W'^e  cannot  solve  this  identity  directly,  but  we  can  use  a  datatype  declaration  to  define  the 
type  state  recursively.  This  is  illustrated  by  the  following  e.xample  of  a  pair  of  coroutines, 
one  producing  and  the  other  consuming  a  sequence  of  integers. 

datatype  state  »  S  of  state  cont 
fun  resume (S  k:  state)  :  state  * 
callccCfn  k’ :  state  cont  => 
throw  k  (S  k’)) 
val  buf  *  ref  0 

fun  produce(n:  int,  cons:  state)  = 

(buf  :=  n;  produce(n+l,  rasume(cons) ) ) 
fun  consume (prod:  state)  ■ 

(print( !buf ) :  consume (resume  prod)) 
fim  pinit  (n:  int)  :  state  * 
callcc(fn  k  :  state  cont  *> 
produce (n.S  k)) 

fun  prun  ()  *  consume(pinit(0)) 

Coroutines  can  be  generalized  to  lightweight  processes  or  threads.  Continuations  have  been 
used  as  the  bausis  for  several  implementations  of  process  facilities  for  Standard  .VIL  of  .N'ew 
Jersey,  some  of  which  use  preemptive  scheduling  [29,  5,  28.  37]. 

The  following  example  uses  stored  continuations  to  implement  a  simple  backtracking 
scheme. 

let 

ved  stack  :  unit  cont  list  ref  »  ref  □ 
fun  pushstate(k  :  unit  cont)  = 
stack  :»  k  ::  '.stack 
fun  popstataO  ■  ctack  :*  tl(!  stack) 
fun  backtrack ()  :  ’a  » 
case  ! stack  of 
□  »>  raise  Error 

I  k  : :  r  ■>  (stack  ;»  r;  throw  k  ()) 
fun  alt(a:unit  ->  unit,b:unit  ->  unit)  » 
callcc(fn  exit  «> 

(callcc(fn  k  ■>  (pushstate  k; 

aO; 

popstateO ; 
throw  exit  ())); 

b())) 

in  . . .  backtracking  application  ... 
end 

Calls  of  alt  can  be  nested  (i.e.  inside  of  the  actions  a  and  b),  and  backtrack  can  be  Ccilled 
in  any  type  context. 
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Another  use  of  continuations  is  to  provide  a  clean,  typed  interface  for  cisynchronous  sig¬ 
nal  handling  [30].  In  Standard  ML  of  New  Jersey  the  type  of  a  signal  handler  is  (int  * 
unit  cont)  ->  unit  cont,  where  the  argument  is  a  pair  consisting  of  a  count  of  pending 
signals  of  the  kind  being  handled  and  the  continuation  representing  the  interrupted  process. 
The  continuation  returned  by  the  signaJ  handler  is  typically  used  to  resume  the  interrupted 
process  after  signals  have  been  unmasked,  but  it  can  also  provide  an  cdternative  continua¬ 
tion  like  aborting  the  computation  and  returning  to  top-level.  The  signal  handling  module 
provides  functions  to  set  handlers  for  each  signal  and  to  mask  all  signals. 

There  is  a  subtle  issue  concerning  the  behavior  of  continuations  in  an  interactive  system. 
Unless  the  context  of  a  continuation  is  carefully  defined  and  controlled  one  can  subvert  the 
type  system.  The  following  sequence  of  top-level  declarations  illustrates  the  problem. 

val  c  *  raf  HONE  :  int  cont  option  ref ; 
val  n;int  »  callccCfn  k  ®>  (c  :®  SOME  k;  2)); 
val  b:bool  » 

let  vail  SOME  k’  »  !c  in  throw  k’  3  and; 

We  are  dealing  with  expression  continuations  that  merely  deliver  a  value;  the  binding  of 
that  value  in  the  top-level  environment  aind  the  printing  of  a  report  for  the  user  are  the 
responsibility  of  the  interactive  top-level.^  So  the  evaluation  context  represented  by  the 
continuation  k  stored  in  c  is  limited  to  the  right  hand  side  of  the  declaration  of  n.  of  type 
int.  When  this  continuation  is  fetched  and  invoked  in  the  right  hand  side  of  the  declaration 
of  b,  that  expression  returns  the  value  3,  which  the  top-level  would  erroneously  interpret  as 
a  boolean  value.  To  prevent  this  anomaly  a  strict  association  between  a  continuation  and 
its  top-level  context  (which  determines  the  type  of  the  answer  returned)  must  be  enforced. 
The  continuation  should  “expire”  when  this  context  changes  and  if  it  is  invoked  after  it  has 
expired  this  should  be  detected  aind  should  generate  an  error  message. 

In  Standard  ML  of  New  Jersey,  expiration  of  continuations  is  enforced  by  timestamping 
continuations.  Each  time  a  top-level  evaluation  is  begun  a  new  stamp  v  is  generated  and 
pushed  onto  a  stack.  The  initial  continuation  used  for  that  evaluation  will  finish  by  popping 
the  stack  and  comparing  the  top  value  with  v.  and  if  they  differ  it  will  signal  an  error. 
stack  of  stamps  is  used  because  "top-level”  evaluations  may  be  nested  when  files  are  loaded 
with  the  use  function. 

.Another  interesting  issue  is  the  relation  between  continuations  and  exception  handling. 
In  the  dynamic  semantics  of  Standard  ML.  an  expression  can  either  produce  a  normal  value, 
or  an  exception  value  indicating  that  an  exception  hais  been  raised  but  not  handled  during 
the  evaluation  of  the  expression.  Therefore  the  dynamic  context  of  an  expression,  i.t.  its 
continuation,  must  be  able  to  deal  with  either  sort  of  result.  In  effect,  one  could  think  of 
the  dynamic  context  of  an  expression  in  ML  as  a  pair  of  continuations,  one  for  the  “normal" 
value  return,  the  other  giving  the  exception  handling  context.  This  suggests  possible  new 
primitives  that  would  either  invoke  a  continuation  with  an  exception  value  rather  than  a 
normal  value,  or  return  the  “exception  handler”  pait  of  a  continuation.  One  pragmatic 
reason  why  such  primitives  are  not  provided  is  that  in  conjunction  with  asynchronous  signal 

'The  interface  between  the  interactive  system  and  the  object  level  evaluation  is  similar  to  a  prompt  [11], 
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handling  they  would  introduce  the  possibility  of  asynchronous  exceptions.  These  would  make 
it  impossible  to  statically  verify  that  a  particular  expression  could  not  raise  a  particular 
exception,  precluding  some  compiler  optimizations. 


3  A  Denotational  Semantics  of  Typing 

In  this  section  we  study  the  soundness  of  type  assignment  for  a  small,  purely  functional, 
monomorphic  fragment  of  ML  extended  with  primitives  for  first-class  continuations.  Ex¬ 
plicit  treatment  of  polymorphism  and  let  is  omitted  since  the  main  issues  do  not  involve 
polymorphism. 

3.1  Type  Assignment 

Consider  the  following  language: 

M  ;:=  X  I  Xx.M  \  M  M'  |  letccx  iuM  |  throw  .V/,V/' 

The  variables  r,  y.  amd  r  range  over  a  set  of  variables,  and  M.  -V,  P.  Q,  and  R  rang.,  over 
the  set  of  terms.  The  expression  letccx  in  A/  binds  x  in  M.  We  use  letcc  in  place  of 
callcc  to  facilitate  comparison  between  the  various  approaches  to  type  assignment. 

Let  b  range  over  some  set  B  of  base  types.  Type  expressions  are  defined  by  the  following 
grammair: 

r  ::=  6  [  — ♦  Tj  ]  r  conf 

typing  context  is  a  partied  function  F  mapping  some  finite  set  of  variables  domlF)  to  type 
expressions.  A  typing  assertion  is  a  triple  F  h  Af  :  r,  where  r  is  a  type  expression. 

We  take  as  given  a  map  type  assigning  a  type  to  each  constant.  (In  a  polymorphic  system 
this  map  would  eissign  a  type  scheme  to  each  constant.)  The  type  assignment  rules  for  the 
above  language  are  as  follows: 


F  H  X  :  F(x) 

( t'AR ) 

F[x  :  Ti]  1-  Af  :  T2 

F  f-  Xx.M  :  Ti  —*  T2 

(.ABS) 

r\-  Th  N:t 

F  h  MN  :  t' 

(APP) 

F[x  :  r  cont]  h  M  :  r 

F  h  letccx inM  :  T 

(letcc) 

F  h  Af  :  r  cont  F  K  iV  :  r 

F  H  throw  M  N  :  r' 

(THROW) 
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3.2  Denotational  Semantics 

We  give  here  a  denotation  semantics  for  the  untyped  language,  in  preparation  for  estal)- 
lishing  a  Milner-type  soundness  theorem.  The  value  space  is  given  by  the  following  domain 
equations: 

Val  =  Bas{BaseVal)  + 

Clsr(  Val  — *•  ( Cont  — +  -h 

Cnt(  Cont) 

Cont  —  Val  —*  Tns 
.4  ns  =  Value{Val)  +  Wrongi) 

■An  answer  is  either  a  value  or  a  special  token  wrong  representing  a  “run-time"  t}-pe  error. 

Let  Env  =  Var  — >■  Val.  Let  the  variables  u.  v,  w.  m,  and  n  range  over  \'al.  the  variable 
K  range  over  Cont.  and  the  variable  p  range  over  Env. 

The  definition  of  the  meaning  function  f'l  :  Env  — *■  Cont  —*  .An.s  is  given  by  induction 
on  the  structure  of  expressions  as  follows: 

I-r]  = 

{Ax.M|  PK  — 

[iV/Alp/c  = 


|letccx  in^Vf] = 
[throw  M  A'l  pK  = 


K(px) 

K{clsr{XvK' .  {M]  p[x:=ujK:')) 
IiV/|  p{Xm.lN]  p{Xn. 
let  clsr{f)=m 
in  fuK  else  wrong)) 

IiV/|  p[x:—  cnf  («)]«: 

IiVf|  p{Xm.  [A'J  p{Xn. 
let  cnt{n')=m 
in  k'u  else  wrong)) 


3.3  Soundness 

To  state  the  semantic  soundness  theorem,  we  require  two  definitions,  one  for  a  value  to  be 
of  a  given  type,  written  v  :  r.  and  one  for  a  continuation  to  accept  values  of  a  given  t^’pe. 
written  k  ::  r.  These  are  defined  simultaneously  by  induction  on  the  structure  of  r  follows: 

1.  V  :  T  holds  iff  u  =±  or 

(a)  T  =  b  and  v  =  bas{w)  with  w  a  value  of  base  type  b. 

(b)  r  =  Ti  — »■  r2  and  v  =  clsr[f)  and  for  all  values  vi  and  continuations  att.  if  cj  : 
and  K2  ::  rj,  then  /(vi)(k2)  ^  wrong. 

(c)  r  =  “i  cont  and  v  =  cnt{K)  and  k  ::  Tj. 

2.  K  ::  T  holds  iff  k{v)  ^  wrong  for  all  v  such  that  v  :  r. 

To  check  that  this  in  fact  is  a  proper  definition,  simply  “expand”  the  definition  of  k  ::  r  in 
the  definition  of  u  :  r,  and  check  that  the  membership  relation  is  used  only  on  subsidiarv 
types  of  the  given  type.  The  relation  u  :  r  is  extended  to  environments  pointwise:  p  :  F  iff 
for  all  X  €  domfF),  p(x)  :  r(x). 
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Theorem  3.1  (Soundness)  //F  H  .V/  :  r  and  p  :  F  and  k  ::  t,  then  l.l/l  pK  -f-  wrong. 

The  proof  is  by  a  straightforward  induction  on  th?  structure  of  the  typing  derivation. 

.A-s  usual  in  continuation  semantics,  we  need  to  provide  an  initial  continuation.  In  order 
to  preserve  the  soundness  of  typing  the  initial  continuation  must  be  chosen  in  such  a  way 
hat  it  yields  a  non- u;ron^  result  for  an  argument  of  the  type  of  the  e.vpression.  .An  obvious 
choice  is  the  continuation  kq  defined  by  /co(u)  =  value{v/,  which  is  essentially  the  identity 
function.  In  an  implementation  the  initial  continuation  might  print  the  result  value  of  the 
computation,  and  hence  must  be  chosen  on  a  case-by-rase  basis,  according  to  the  type  of 
the  expression  being  evrtluated. 

3.4  Observational  Soundness 

In  contrast  to  languages  with  a  “direct"  semantics,  the  soundness  theorem  does  not  yield 
positive  results  about  typing.  In  particular,  we  may  not  conclude  that  the  value  of  an 
arbitrary  expression  of  a  base  type  {e.g.,  int)  yields  a  result  of  the  expected  form  [t.g..  a 
numeral).  .A  natural  attempt  to  obtain  such  results  from  the  soundness  theorem  proceeds  by 
choosing  the  continuation  argument  to  be  the  function  which  yields  wrong  except  on  values 
of  the  desired  type.  However,  this  overlooks  the  fact  that  in  a  language  with  continuat’on- 
passing  primitives,  the  result  of  ev-aluating  an  open  expression  need  not  be  given  in  terms  of 
its  continuation  argument.  This  suggests  that  the  best  we  can  hope  for  is  a  “observational 
soundness”  theorem  that  yields  positive  results  about  closed  e.xpressions  of  base  type. 

It  seems  clear,  on  the  basis  of  operational  intuitions,  that  evaluation  of  a  complete  pro¬ 
gram  either  goes  wrong,  or  else  passes  a  value  to  the  initial  continuation.  Unfortunately 
these  operational  intuitions  do  not  seem  to  transfer  readily  to  the  setting  of  the  untyped 
denotationaJ  semantics  given  above.  We  give  here  a  brief  sketch  of  the  argument.  The  main 
idea  is  to  prove  that  complete  programs  are  "‘non-escaping*’  in  the  sense  that  their  denotation 
is  either  wrong,  or  is  determined  as  a  function  of  the  initial  continuation.  Since  the  semantics 
of  certciin  closed  expression  involves  the  semantics  of  open  sub-expressions,  we  must  in  fact 
prove  a  stronger  result  that  takes  account  of  environments  and  intermediate  continuations. 
This  entails  extending  the  “non-escaping”  property  to  arbitrary  values,  and  to  do  so  appears 
to  require  an  inclusive  predicate  argument  similar  to  that  considered  by  Reynolds  [33].  Given 
that  such  a  predicate  exists,  we  may  choose  the  initial  continuation  as  discussed  above,  and 
conclude,  by  the  non-escaping  property,  that  well-typed  closed  terms  of  base  type  evaluate 
to  values  of  that  type.  Although  it  seems  plausible  that  the  required  predicate  exists,  we 
have  not  proved  this,  and  turn  instead  to  a  more  straightforward  argument. 

The  need  for  an  inclusive  predicate  argument  can  be  traced  to  the  rich  structure  of  the 
semantic  domain  needed  to  interpret  untyped  programs.  By  exploiting  the  type  structure  of 
the  language,  the  complexity  of  reflexive  domains  can  be  avoided  (while  still  admitting  ex¬ 
tensions  such  as  fix).  The  fundamental  idea  is  to  adapt  the  methods  of  Meyer  and  Wand  [22], 
and  make  use  of  standard  results  of  the  typed  A-calculus  to  obtain  the  desired  result.  The 
main  idea  is  to  define  the  meaning  of  a  term  M  in  our  illustrative  language  as  the  meaning 
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of  its  cps  transform.  M.  defined  as  follows: 

X 

ITm 

_ MN 

letccx  in.V/ 
throw  M N 

(In  fact,  the  Standard  ML  of  New  Jersey  compiler  is  based  on  a  similar  transformation  i 
To  relate  the  type  of  a  term  M  to  the  type  of  its  cps  transform,  we  associate  to  each 
type  r  of  the  illustrative  language,  a  simple  type  r’  given  by 

6'  =  b 

{rr-<’T)‘  =  <T’— ((r'—o)— tt) 

(rcoraf)*  =  r'—*a 

where  q  is  a  fixed,  but  arbitrary,  ba.se  type.  The  function  (  )*  is  extended  to  t}'ping  contexts 
pointwise;  if  T  is  a  typing  context,  then  r*(j)  is  the  typing  context  that  assigns  to  each 
variable  x  €  dom(r)  the  simple  type  r(x)’. 

The  following  lemma  relates  the  type  of  a  term  in  the  illustrative  language  to  the  type 
of  its  cps  transform: 

Lemma  3.2  [fVh  \I  :  r.  then  T*  b'  M  :  (r*— ^a)— *-a. 

(Here  b'''*  denotes  derivability  in  the  simply-typed  A-calculus.)  The  proof  is  a  simple  induc¬ 
tion  on  the  structure  of  M.  taJting  account  of  the  definition  of  M . 

Let  A  be  any  model  of  the  simply-typed  A-calculus  with  carrier  set  .A’  for  each  type  r 
and  application  operation  •  :  .4''”’’  — ►  .4''  — *•  .4’’.  We  say  that  an  environment  p  matches 
a  typing  context  F  iff  /j(x)  €  .4^^''*  for  each  x  €  dom(r).  It  is  a  standard  result  that  if 
r  b''"  \I  :  T  and  p  matches  F,  then  v4|[iV/|p  €  .4’’  [25].  Hence  if  we  define  i[.\/|  to  be 
>f{.V/|.  then  |:V/J />  is  in  the  set  ■»•— <»  '■  soever  p  matches  F'.  Now  if  A/  is  a  closed 

term  of  base  type  b.  we  may  take  p  to  be  me  empty  environment,  and  a  =  h.  to  obtain 
|.V/| /)  -E  .4b— i  since  the  identity  function  on  type  h  is  denotable  by  a  \  term,  and 

since  M  is  a  model  of  the  typed  A  calculus,  we  may  apply  this  to  id},,  the  initial  continuation, 
to  obtain  [.V/]|  p  ■  idb  €  A*’-  In  other  words,  the  value  of  M.  when  applied  to  the  identity  as 
initial  continuation,  is  a  value  of  base  type  b.  In  the  case  of  cpo-based  models  (which  are 
needed  to  interpret  arbitrary  recursion)  with  base  types  interpreted  as  flat  epo  s,  the  result 
is  either  X.  or  a  “true"  value  of  the  base  type.  Note  that  this  argument  does  not  extend  to 
higher  types  r  since  the  definition  of  r'  for  higher  types  involves  a.  and  hence  we  may  not 
simply  choose  a  to  coincide  with  r. 

3.5  Continuations  as  Functions 

Two  alternative  type  systems  given  in  the  introduction  rely  on  the  representation  of  continu¬ 
ations  as  functions.  We  consider  here  the  semantics  of  typing  for  the  system  based  on  empty- 
types,  and  for  the  system  based  on  regarding  continuations  as  functions  of  polymorphic 
result  type. 


=  \k.kx 
=  Xk.k{\x.M] 

=  Xk.M  ( Xm.y  ( Xn.mnK ) ) 
=  Xk.(Xx.\I)hk 
=  Xk.JTN 
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To  express  the  idea  that  a  continuation  is  a  function  that  never  returns,  we  introduce 
a  type,  void,  with  no  values,  and  regard  a  continuation  accepting  values  of  type  r  as  a 
function  of  type  r  — *•  void.  This  leads  to  the  following  typing  rule  for  letcc: 


r[i  :  T  -*  void]  y-  M  :  r 
r  h  letcc  X  in  iV/  :  r 


(CALLCC-EMPTY) 


Since  the  result  of  application  of  a  continuation  is  now  void,  we  must  introduce,  in  compen¬ 
sation,  a  map  ignore  witnessing  the  inclusion  of  void  into  every  type  r; 

r  H  A/  ;  void 

- - - -  (GIVE-UP) 

1  r  Ignore  M  :  r 

(These  two  rules  have  the  form  of  Pierce's  Law  and  false  elimination,  respectively:  see  [lo] 
for  further  discussion.)  The  expression  throw M.V  is  now  defined  as  ignore (.V/.V).  For  the 
polymorphic  variant,  the  typing  rule  for  letcc  appears  in  the  introduction. 

The  denotational  semantics  must  be  changed  to  reflect  the  representation  of  continuations 
a,s  functions.  The  domain  equation  for  values  is  simplified  to 

Val  =  Bas{BaseVal)  +  Clsr{  Val  — ►  Cont  — *■  Ans). 


and  the  semantic  equations  become: 

M  pK 
{Xx.M]  pK 
IM^V]  PK 


[letcc  r  inM]  pn 
[ignore  M]  pK 


k{px) 

K{clsr{XvK'.  [iV/|  p[x:=v]«:')) 
|iW|  p{Xm.  |iV]  p{Xn. 
let  clsr[f)=m 
in  fuK  else  wrong)) 

|iVf|  p[x\-=  clsr[XvK'  .kv)\k 
|iV/J  PK 


\  continuation  is  represented  by  a  closure  that  ignores  its  continuation  argument  [321.  The 
definition  of  the  relation  v  :  r  remains  essentially  the  same,  ignoring  the  clause  for  continua¬ 
tion  types.  Since  void  is  a  base  type  with  no  proper  elements,  if  v  :  void,  then  v  =±:  there 
axe  no  terminating  values  of  type  void. 

The  proof  of  the  soundness  theorem  for  the  system  with  an  empty  type  relies  on  two 
fcicts.  First,  we  must  show  that  a  continuation  k  regarded  as  a  closure  has  type  r  — >•  void 
whenever  k  ::  r.  Suppose  that  v  :  r  and  that  k'  ::  void.  Then  [Xv.Xk' .k{v))  v  k'  =  k{v). 
Now  since  k  ::  r  «ind  u  :  r,  it  follows  that  «(u)  ^  wrong,  as  required.  Second,  we  must 
show  that  ignore  M  may  be  assigned  an  arbitrary  type  whenever  M  is  of  type  void.  But 
if  K  ::  r,  then  k  ::  void  since  X:  r  for  any  r,  and  hence  the  result  follows  by  induction. 
For  the  case  of  polymorphic  continuations,  we  need  only  remark  that  Vt.r(t)  is  defined  by 
intersection  over  all  monotypes,  and  note  that  the  above  argument  shows  that  if  k  r,  then 
At;.A/c'./c(u)  :  r— ♦r'  for  any  type  r'  (not  just  void). 
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4  Extending  the  Definition  of  Standard  ML 

An  operational  semantics  for  our  language  presented  in  the  relational  semantics  style  of  the 
formal  definition  of  Standard  ML  [24]  may  be  obtained  from  the  denotational  semantics  by 
a  process  of  “defunctionalization”  [32]  whereby  closures  and  continuations  are  represented 
by  finitary  objects  that  are  then  ‘‘interpreted”  on  an  argument,  rather  than  simply  applied 
to  it.  The  resulting  semantics  differs  substantially  from  the  dynamic  semantics  of  Standard 
ML.  This  may  be  taken  as  evidence  that  the  addition  of  callcc  to  Standard  ML  would  be 
a  substantial  change,  rather  than  an  incremental  modification,  to  the  language. 

The  “finitary  objects"  of  the  operational  semantics  are  defined  by  the  following  grammar: 

V  ::=  BAS(5)  I  CLSR(x,.V/.  £)  |  CXT(A') 

K  ;:=  TOP  1  F.a.rg(.V.£.  A')  1  .\pp(l'.  A')  i 
TARG(A'.£)  1  THR(V) 

A  ::=  V'ALU(V')  |  WRONG 

where  £  is  a  basic  value  (of  unspecified  structure),  and  £  is  a  finite  function  mapping 
variables  to  finitary  values. 

The  dynamic  operational  semantics  is  defined  in  terjiixS  of  two  judgement  forms.  £;  K  - 
.V/  A  and  V  h  A'  =»  .4.  The  derivation  rules  for  these  judgements  are  as  follows: 


£(x)  h  A'  =>•  .4 

E:  K  ^  X  A 

(0-VAR  1 

CLSR(x.-W.£)  1-  K  =»  A 

E:  K  h  Xx.M  ^  A 

(0-ABS) 

£:  FARG(iV,  £,  K)  r  M  ^  A 

£;  A'  h  MN  =>  A 

(0-APPLY) 

£[x=cnt(A')]:  A'  h  .V/  =>  .4 
£;  K  h  letccx  inM  =*■  .4 

1  O-LETCC ) 

£;  TARG(:V.  £)  h  M  =►  .4 
£;  A'  H  throw  M  N  ^  A 

(O-THROW) 

V  h  TOP  VALUlV) 

(O-TOP) 

E:APPiV.K)\-  N  =>  A 

V  h  FARG(iV,  £,  A')  =>  .4 

(O-FARG) 

£(x=V^j;  A'  1-  M  A 

V  h  app(clsr(i,M.£),  A')  =>  A 

(O-APP) 

£;THR(V')  h  N  =>  a 

V  h  T\RG{N,E)  ^  A 

(O-TARG) 

13 


(0-THR  ) 


V  K  =>  .4 

V  H  THR(CNT(A'))  =>  .4 

Here  the  initial  continuation,  designated  TOP.  is  eixiomatized  as  the  trivial  insertion  of 
values  into  answers.  Other  choices  axe  possible. 

There  is  an  intriguing  parallel  between  this  operational  semantics  and  a  call-by-value 
variant  of  graph  reduction.  The  idea  is  that  the  argument  K  in  E:K  H-  .V/  ^  .4  may  be 
thought  of  as  a  ‘‘marked”  spine  stack,  with  the  marks  indicating  whether  or  not  the  argument 
position  has  been  evaluated.  Rule  O-APPLY  “pushes”  a  node  onto  the  spine  stack,  marking  it 
as  having  an  unevaluated  argument.  Rules  o-var.  and  0-aBS  are  "turning  points"  at  which 
traversal  of  the  e.xpression  reverses  direction  by  sending  explicit  values  back  up  toward  the 
root.  This  traversal  is  carried  out  by  the  rules  for  interpreting  a  continuation.  Rules  o- 
F.ARG  and  0-TARG  cover  the  case  where  the  argument  position  is  as  yet  unevaluated,  and 
proceed  to  evaluate  it,  marking  the  node  appropriately.  Upon  return  to  such  a  node,  the 
actual  application  or  throw  is  carried  out.  either  by  evaluating  the  body  of  the  closure  in 
the  appropriate  environment,  or  by  switching  contexts  entirely. 

The  soundness  theorem  for  typing  may  be  proved  for  the  operational  semantics  by  pro¬ 
ceeding  along  much  the  same  lines  as  for  the  denotational  caise.  First,  we  must  augment  the 
evaluation  relation  to  include  error  checking  rules  that  make  explicit  the  notion  of  "going 
wrong.”  These  axe; 


V'  ^  clsr(x.A/.  £) 

V  h  APP(U'.A')  WRONG 

V'  #  cnt(£0 

V  H  THR(U',A')  =»  WRONG 

We  then  define  the  relations  V  :  r  and  A'  ::  t  more  or  less  as  before, 
relying  on  the  existence  of  suitable  functions  in  the  value  space,  we 
operationcil  semantics. 

1.  V  :  T  holds  iff 

(a)  T  =  b  and  V  =  valU(I'U)  with  W  a  value  of  type  6; 

(b)  r  =  Ti  — f  72  and  V  =  CLSR(x,  M,  £)  and  for  every  Vj  and  A'2,  if  V,  :  A'2  ::  r^. 

and  E[x  =  V\];  A'2  H  M  =>  .4,  then  4  WRONG: 

(c)  T  =  Ti  cont  and  V  =  CNT(A')  and  A'  ::  n. 

2.  K  ::  r  holds  iff  for  every  V  such  that  U  :  r,  if  U  1-  A'  =»  .4,  then  .4  ^  wrong. 

The  soundness  theorem  for  the  operational  semantics  is  as  follows: 

Theorem  4.1  IfThM-.r  and  E  :  T  and  K  ::  r  and  E\  K  H  M  =>  4,  then  .4  ^  WRONG. 

In  contrast  to  the  domain-theoretic  semantics,  the  proof  of  the  soundness  theorem  is 
significantly  complicated  by  the  introduction  of  fixed-point  operators  for  defining  recursive 
functions;  see  [23]  for  a  careful  discussion  of  a  closely-related  problem  in  the  setting  of  natural 
semantics. 


(O-THR-.X  ) 

except  that  instead  of 
appeal  directly  to  the 
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5  Conclusions 


First-class  continuations  are  a  powerful  tool  for  implementing  sophisticated  control  con¬ 
structs  like  coroutines,  processes,  backtracking,  and  asynchronous  signals.  Until  now  they 
have  been  studied  and  employed  in  the  context  of  dynamically  typed  languages  like  Scheme. 
We  have  been  pleasantly  surprised  to  discover  that  first-class  continuations  can  also  be  ac¬ 
commodated  in  a  polymorphically  typed  language  like  ML  simply  by  adding  a  new  primitive 
type  with  a  couple  of  associated  operations.  In  fact,  the  added  discipline  of  the  ML  type  sys¬ 
tem  seems  to  simplify  programming  with  first-class  continuations.  We  have  made  the  hrst 
steps  toward  integrating  first-class  continuations  into  the  semantics  of  Standard  ML  and 
verifying  the  metaproperties  of  soundness  and  observational  soundness,  but  it  is  clear  that 
e.xtensivp  work  is  required  to  integrate  continuations  fully  into  the  definition  of  Standard 
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